Use native payment asset labels in UI - #122

Outcome

Dotify no longer displays hard-coded DOT labels across the Classic unlock and artist payment UI. Payment amounts now use the native runtime asset resolved from the connected EVM chain, so Product DevNet/Paseo surfaces display PAS while DOT-backed chains can display DOT.

Issue and context

Refs #85. PR #121 made Classic unlock intents explicitly carry the native runtime asset, but several user-facing components still rendered price strings as DOT. That was misleading on the current Product DevNet/Paseo rail, where the runtime-native token label is PAS.

This PR keeps the money boundary unchanged: pricePlanck remains the authoritative payment amount, Classic unlock still submits msg.value through RuntimeWritePort, and CASH remains unsupported until PCF/Product confirms a settlement receipt or bridge model.

Architecture and key concepts

The catalog hook already resolves nativeRuntimePaymentAsset from the connected chain. This PR exposes that asset through CatalogProvider consumers and threads the symbol into presentational surfaces that render Classic prices.

Runtime flow:

UI resolves EVM chain -> nativeRuntimePaymentAsset -> catalog/player/studio labels -> Classic payment intent -> RuntimeWritePort -> musicRoyPayAccess(contentHash) + msg.value.

No contract, backend, CORS, Fly, Netlify, or env setting changes are included.

How it works

• web/src/hooks/useCatalog.ts now returns nativeRuntimePaymentAsset.
• web/src/features/payments/paymentModel.ts adds nativeRuntimeAmountLabel for visible native amount strings.
• Catalog cards, artist profile cards, player access state, AccessGateOverlay, wallet/account views, and Artist Studio tabs use the resolved symbol.
• The Classic unlock e2e now expects PAS for the current Product DevNet/Paseo config.
• PR documentation now requires pre-PR dependency/SDK, improvement, and philosophical alignment checks.

Design decisions and tradeoffs

I did not rename priceDot or formatWeiAsDot in this PR. Those names are historical and wider than the display bug: they touch API shapes, track types, artist publish, mocks, and tests. The safer scope is to make visible labels honest now, then handle semantic renaming in a dedicated compatibility PR.

I did not update Product SDK dependencies here. The official npm snapshot shows drift and audit risk, but changing SDK/PAPI versions would materially broaden this UI-label PR.

Security, failure, and operations

Authoritative payment amount remains pricePlanck when available; display strings do not drive settlement. Unknown chain metadata falls back to the existing native asset fallback, and this PR does not introduce any frontend secrets or deployment configuration.

No deployment configuration update is required: no env vars, origins, Fly, Netlify, mounts, scaling, or runtime settings changed.

Review guide

Suggested order

1. web/src/features/payments/paymentModel.ts and paymentModel.test.ts: verify the display formatter is intentionally separate from amountPlanck settlement.
2. web/src/hooks/useCatalog.ts: verify the resolved asset is exposed without changing catalog loading or payment execution.
3. web/src/components/AccessGateOverlay.tsx and web/src/views/PlayerView.tsx: verify the unlock gate and player state use the resolved symbol.
4. web/src/views/ListenView.tsx, ArtistProfileView.tsx, YouView.tsx, WalletModal.tsx, and artist tabs: verify all user-facing Classic amount labels receive the symbol.
5. web/e2e/classic-unlock.spec.ts: verify the Product DevNet/Paseo e2e expectation is PAS.
6. docs and PR template: verify the new PR standard is clear and not over-broad.

Verify carefully

• No UI path still tells a Product DevNet user they are paying DOT for Classic unlock.
• pricePlanck remains authoritative and no payment amount is rebuilt from display labels.
• CASH remains non-executable and is not silently converted into native runtime payment.
• The new pre-PR checklist is visible in both docs and PR template.

Validation

Known limitations and follow-ups

• Dependency drift should be handled in a separate SDK/dependency PR: Product SDK 0.20.1 -> 0.23.0, host 0.15.1 -> 0.16.0, statement-store 0.6.2 -> 0.6.5, descriptors 0.8.0 -> 0.10.0, polkadot-api 1.23.3 -> 3.0.0, React 18 -> 19, Vite 6 -> 8, TypeScript 5.6 -> 7. These are not safe to opportunistically update here.
• npm audit currently reports high severity issues through deepmerge-ts/write-package/@polkadot-api/cli/Product SDK and nanoid/@novasamatech/host-api. That needs a dedicated dependency/security pass.
• Internal names like priceDot and formatWeiAsDot remain historical and should be renamed only after API/catalog compatibility is planned.

Pre-PR alignment check

• Dependency / SDK currency: checked against npm registry before opening; drift listed above.
• Improvement flags: dependency/security PR needed; historical native amount naming should be cleaned in a separate compatibility PR.
• Philosophical alignment: this strengthens honest access boundaries and low-friction trust. A user should see the token they are actually asked to pay, without having to understand Product DevNet internals.

Metadata checklist

• Backlog issue linked with reference semantics
• Local backlog document linked: docs/backlog/polkadot-product-readiness-and-killer-dapp-roadmap.md
• Added to Project 5 (Dotify sprints)
• Project Priority, Track, Phase, Type, and Backlog doc mirror the issue
• Workflow status matches draft/review state
• Assignee set
• Applicable labels set
• Applicable milestone set, or confirmed none exists
• Reviewers requested when ownership is known
• Draft/ready state is intentional